Summary

Several behavior-preserving cleanups in sdk-core's http/pipeline/steps, where the sync/async step pairs had drifted into duplicated helper blocks. All changes are internal — no public signatures move, so apiCheck is unaffected — and land as separate commits.

Changes

Extract RetryPolicySupport (the structural one). DefaultRetryStep and DefaultAsyncRetryStep carried byte-for-byte copies of the entire stateless retry policy: options clamping, the RetrySettings backoff view, re-sendability gating, interrupt normalisation, predicate invocation, the caller delay override, and fixed/exponential backoff. Only the per-call loop machinery and terminal-failure paths genuinely differ. The policy now lives in one internal class RetryPolicySupport; both steps hold a support and delegate. Each step keeps what actually differs — the per-call should-retry checks (which read tryCount/suppressed), the distinct terminal paths, the protected open delay hooks, and closeQuietly with its deliberately different catch width (sync swallows IOException, async swallows Exception).

RetryPolicySupport takes (rawOptions, logger) — not clock: none of the helpers that moved into it use the clock, and the only clock consumer (retryAfterFromHeaders) deliberately stays on each step. A clock field there would be dead and trip detekt.

Add HttpRetryOptions.withMaxRetries. HttpRetryOptions isn't a data class, so the negative-maxRetries clamp hand-rebuilt all eight fields through the constructor. A single internal copy helper lives on the type that owns the fields, and RetryPolicySupport.clampOptions collapses to one line. (A targeted helper beats converting to data class, which would push copy/componentN into the public API.)

Hoist offersBearerChallenge. Both bearer steps defined an identical private offersBearerChallenge + "bearer" constant. They move to one top-level internal function and constant in BearerTokenAuthStep.kt (mirroring the existing top-level defaultShouldRetryResponse); the async file drops its copy and its now-orphaned AuthChallengeParser import. evictRejectedToken stays per-step (it touches each step's own lock/cache).

Fold the AsyncAuthStep challenge carrier. handleChallenge ran the challenge future through a handle that only boxed (value, error) into a one-field HookOutcome, then a thenCompose that unboxed it to do the work. A single handle { … }.thenCompose { it } does the close/fail/dispatch decision directly, removing the carrier type and a composition stage. Behaviour is identical across all three completion paths (no-retry, retry, hook error).

Drop the throwaway MDC capture. DefaultAsyncInstrumentationStep initialised mdc with an MdcSnapshot.capture() that was overwritten on the first line inside the trace-context scope — one wasted snapshot per async request. lateinit var expresses the intent (assigned inside the scope, read only after it runs) without the wasted capture.

Verification

Locally on sdk-core: full test suite, compileKotlin (under allWarningsAsErrors), ktlint, detekt, and apiCheck all pass. I traced the AsyncAuthStep fold across normal/retry/exceptional challenge completions and confirmed the retry-policy helpers are byte-identical between the two stacks before extraction.

Closes #169